Method for scheduling future orders on an electronic commodity trading system

ABSTRACT

A method is provided for placing a trade order for a commodity on an electronic exchange to da executed at a future time, said method composing the steps of displaying a trading screen for a commodity market, said trading screen including a future time schedule and an order entry region corresponding to each future time segment of the future time schedule, and scheduling an order corresponding to a future time segment by locating a pointer of a user device within an order entry region corresponding to the future time segment and sending an input signal via the pointer.

REFERENCE TO PREVIOUSLY FILED APPLICATION

The present application hereby incorporates by reference U.S. patentapplication having Ser. No. 11/431,140, filed May 8, 2008, entitled“Smooth Scrolling far Software Application.”

FIELD OF THE INVENTION

The present invention relates to a method of trading commodities over anelectronic exchange, and more particularly, to a method for more quicklyand efficiently scheduling future buy or sell orders to he executed atprecise future dates and times.

BACKGROUND OF THE PRESENT INVENTION

Commodities have been traded in the same way for hundreds of years. TheChicago Board of Trade (“CBOT”) began trading commodities in the 1800's.Since the inception of the CBOT, many different exchanges all over theworld have been created and trade commodities.

Due to the recent evolution of the internet, electronic commoditytrading has become a standard feature of exchanges. This has permittedvast accessibility to various exchanges without requiring that a user bepresent within the exchange and without the necessity of “paper trades.”Not only has the use of electronic trading greatly increased the abilityfor users to trade commodities, but electronic trading has alsoincreased the volatility of the exchanges, since there are more usersthat have easier and faster assess to the exchanges.

Electronic trading of commodities is achieved through a combination ofexchange hosts, internet service providers (“ISPs”) and applicationservice providers (“ASPs”). The exchange hosts are primarily responsiblefor order routing, price dissemination and connectivity.

The ASPs that are utilized in electronic commodities trading areresponsible for, among other things, maintaining connectivity, hosts andclients. Connectivity is maintained with respect to exchange hoststhrough bidirectional communication with redundancy. The hosts areresponsible for risk management throughout the trading day as well asthe back office integration/imports. Hosts are also responsible forconnectivity of the client session management, price dissemination andorder routing.

The client is what the user interacts with directly. The client isresponsible for connectivity through the internet or through directconnection to the hosted server environment. The client includes asession management feature which will monitor client connectivity to thehosted server environment. Moreover, the client will typically include aconfigurable display that includes prices not only of the last trade,but also of the depth of market. The client also allows the user tomanipulate orders, keep track of an order book and monitor accountstatus, including balances, profit and loss and positions. Each of theexchanges has requirements in order for the hosts and the clients toparticipate in the market. While the exchange interface is the same forall participants, the different ASPs and proprietary systems interfacescan and do differ.

Different commodity trading companies typically include a custom tradingfront-end or platform which each company markets as providing a tradingadvantage over another commodity trading company. The general advantagesan individual trader is seeking are speed and accuracy. Thus, acommodity trading company having a front-end platform that increasesspeed and accuracy over competing front-end platforms will give thatcommodity trading company a marketing advantage.

Accordingly, there is a continued need for commodity trading companiesto provide features on their front-end platform which enable their usersto schedule future trades faster and mere accurately than competingcommodity trading companies.

OBJECT AND SUMMARY OF THE INVENTION

In view of the foregoing, an object of the present invention is toprovide a front-end platform that enables e trader accessing anelectronic commodity exchange to more quickly and accurately schedulecommodity orders to be executed at specific future times.

In accordance with the present invention, a method is provided forplacing a trade order for a commodity on an electronic exchange to beexecuted at a future time, said method comprising the steps ofdisplaying a trading screen for a commodity market, said trading screenincluding a future time schedule and an order entry region correspondingto each future time segment of the future time schedule, and schedulingan order corresponding to a future time segment by locating a pointer ofa user device within an order entry region corresponding to the futuretime segment and sending an input signal via the pointer.

The present invention provides a commodity trader with improvedefficiency and accuracy in placing and executing trade orders forcommodities on an electronic exchange. Other features and advantages ofthe present invention will become apparent to those skilled in the artfrom the following detailed description. It should be understood thatthe detailed description and specific examples, while indicating thepreferred embodiment of the present invention, are given by way ofillustration and not limitation. Many changes and modifications withinthe scope of the present invention may be made without departing fromthe spirit of the invention, and the invention includes all suchmodifications.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart of a preferred method configured in accordancewith the present invention;

FIGS. 2 a-2 g are sequential displays of a front-end platform configuredin accordance with the present invention for scheduling orders to beexecuted at future times; end

FIG. 3 illustrates network connections, between multiples exchanges anda client in accordance with a preferred embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now to the drawings, FIG. 1 shows a flowchart of the preferredmethod configured in accordance with the present invention. In thepreferred embodiment, the method of the present invention is implementedon a computer or electronic terminal. The computer is able tocommunicate directly or indirectly via intermediate devices with anexchange to receive and transmit market, commodity, and trading orderinformation. The present invention is preferably implemented on anyexisting or future terminal or device with the processing capability toperform the functions described herein. The scope of the presentinvention is not limited to the type of terminal or device used.Furthermore, the present invention is not necessarily used on theinternet.

The description refers to a single click of a mouse or other inputdevice as means for a user to interact with a terminal display. While amouse is a preferred method of interacting with the terminal display ofthe present invention, the scope of the present invention is not limitedto the use of a mouse as an input device or to the click of a mousebutton as a user's single action. Instead, any action by a user of thepresent invention, whether including one or more clicks of a mousebutton or other input device, is considered a single action or step ofthe user for purposes of the present invention.

Turning to flowchart 100, the preferred method of the present inventionbegins at step 102 where a computer screen implementing the presentinvention displays a trading screen for a commodity market, such as theChicago Board of Trade (CBOT). The displayed trading screen includes afutures time schedule end order entry regions corresponding to futuretime segments.

Next, at step 104, the method checks to determine whether a user desiresto schedule a buy order at a specific future time. In order to schedulea future buy order, a user simply locates a display pointer, such as amouse arrow, within a buy order region corresponding to a specificfuture time, and makes a single click on his or her input device, suchas a mouse. These buy order steps are illustrated in steps 106 and 108of the flowchart 100. The method then moves to step 110 to determine ifthe user is inputting a request to schedule a sell order. If no buyorder is being inputted by the user at step 104, then method movesdirectly to step 110 to determine if the user is inputting a request toschedule a sell order.

To schedule a future sell order at step 110, the user simply locates thedisplay pointer within a self order region corresponding to a specificfuture time and makes a single click on the input device. These stepsare illustrated in steps 112 and 114 of the flowchart 100. The methodthen moves to step 116 to determine if the user is requesting toschedule another future order via the input device by locating thepointer within the buy or sell order regions. Also, if no sell order isbeing inputted by the user at step 110, then the method moves directlyto step 116 to determine if the user is requesting to schedule any moreorders whether they be buys or sells.

If a new future buy or sell order is not being requested by the user bylocating the pointer within the schedule buy order region or schedulesell order region of the displayed trading screen, the method thenchecks to determine if an order has been scheduled for the current timeat step 118. If no order has been scheduled for the current time, thenthe method goes directly to step 122 to check if any other orders havebeen scheduled. If an order has been scheduled for the current time atstep 118, then the method moves to step 120 to execute the buy or sellorder scheduled to the current time. Afterwards, the method moves tostep 122 to determine if any scheduled orders remain to be executed.

At step 122, if any scheduled future orders remain to be executed, themethod returns to step 118. If no orders remain to be executed, then themethod has processed all the scheduled orders.

Referring now to FIGS. 2 a-2 f, these drawings illustrate in sequentialorder the process of scheduling a future order on a commodity exchangein accordance with the present invention. Referring first to FIG. 2 a,shown is a commodity trading display 10 for a front-end platformconfigured in accordance with the present invention. In accordance withthe present invention, the display 10 includes at least six columns;time 12, market profile bracket 14, my bid or my buy order status 16,schedule buy order region 18, schedule sell order region 20, and myoffer or my sell status 22. Under the default configuration, the timecolumn 12 lists one minute time increments from the present time tothirty minutes in the future. The intersection between the columns 12,14, 16, 18, 20, 22 and the time segments or time increments 24 createcells 26. The cells 26 within the buy (bid) 18 and sell (offer) 20columns are the order entry regions that accept user input when apointer 28 is located within these regions and a user clicks on biscomputer mouse or other input device to trigger the submission ofactivation order to a computer server. A trader may cancel an order bylocating his or her pointer 28 within call 26 of my bid 16 or my offer22 corresponding to a previously activated or scheduled buy or orderregion 18, 20 and clicking on his or her input device.

The buy and sell order regions 18 and 20, respectively, are horizontallyaligned with the time increments 24 displayed within the time column 12.Clicking on an order entry region 18, 20 provides final order parametersrequired to submit a time activation order consisting of time andbuy/sell. All other order parameters are pre-specified in other areas ofthe front-end platform outside the time activation component. Suchparameters include quantity, order type (limit, stop, stop limit),clearing instruction rules, market and account.

The market profile bracket column 14 displays a character thatrepresents a bracket of time. These brackets of time are configurable ascommodity traders desire to see different commodities, and differentcommodity markets have different trading schedules. The concept ofmarket profile brackets is an industry standard, however, displaying themarket profile brackets in a column 14 makes it easier for time basedtraders to schedule orders based on what other market profile basedtools are telling the traders. The working bids and offers columns 16,22 display the total quantity of orders scheduled to be bought or soldat the corresponding time interval 24 in the time column 12.

Display 10 illustrates the states of a users account before any futurebuy or sell orders have been schedule. FIG. 2 a also includesexplanation arrows #1-9 to illustrate different areas of the displayscreen 10. Explanation arrow #1 shows that the order quantity has beenset to 1 lot. Thus, each time a trader places his pointer 28 in a buyorder region 18 and single clicks his or her mouse, a buy order for 1lot will be scheduled. If the lot quantity was set to two, then eachsingle click of the mouse would schedule two lot orders. Explanationarrow #2 indicates that the order type is a market order. Thus, eachclick of the mouse by a user when the pointer is within an order regionwill schedule a market order. The type of order can be changed to alimit or stop limit order. Explanation arrow #3 shows where the currenttime is displayed. Explanation arrow #4 illustrates the time segments orincrements, and explanation arrow #5 shows the market, profile brackets,whose default is set to thirty minute brackets. Explanation arrow #6shows the buy order status column 16, and explanation arrow #7 shows theschedule buy order region 18. Explanation arrow #8 shows schedule sellorder region 20, and explanation arrow #9 shows the sell order status22.

FIG. 2 b, shows the display 10 after a buy for one lot has beenscheduled for 17:90 by placing pointer 28 and clicking in a sell 26 ofthe order buy region column 18, as shown by explanation arrow #1.Explanation arrow #2 shows that the buy order is being held on theserver and is awaiting submission.

FIG. 2 c, illustrates the display 10 after a sell order for one lot hasbeen scheduled for 17:10 by placing pointer 28 and clicking in a cell 26of the schedule sell order region 20, as shown by explanation arrow #1.Explanation arrow #2 shows that the sell order is being held on theserver and is awaiting submission.

FIG. 2 d shows that one time increment, in this example one minute, haselapsed thus shifting all of the columns 12, 14, 16, 18, 20, 22 up onerow.

FIG. 2 e shows another time increment (one minute) has elapsed sinceFIG. 2 d, as illustrated by explanation arrow 1, thus shifting all thecolumns 12, 14, 16, 18, 20, 22 up one row. Furthermore, explanationarrow #2 shows that the scheduled buy order for 17:09 has now executedand filled, as 17:09 is now the current time.

FIG. 2 f shows another time increment (one minute) has elapsed sinceFIG. 2 e, thus shifting all of the columns 12, 14, 16, 16, 20, 22 up byone row.

FIG. 2 g shows another time increment (one minute) has elapsed sinceFIG. 2 f, as illustrated by explanation arrow 1, thus shifting all thecolumns up by one row. Furthermore, explanation arrow #2 shows that thescheduled sell order for 17:10 has now executed and filled, as 17:10 isnew the current time.

FIG. 3 illustrates a network connection between multiple exchanges and aclient configured in accordance with a preferred method of the presentinvention. Several exchange hosted environments are illustrated,including the Chicago Board of Trade (CBOT) 302, the Chicago MercantileExchange (CME) 304, and the European Electronic Exchange (Eurex) 306.The various exchange hosted environments 300 are connected to a hostedtrading platform environment 310 via direct copper or fiber connection308. Specifically, the exchange hosted environments 302, 304, and 306interface directly with exchange handlers 312 via the direct connections308. Software applications for use with the hosted trading platformenvironment 310 of the present invention also preferably include aserver component. The server component is preferably an n-tierdistributed application that is designed to be robust, secure andscalable. The server preferably consists of a number of tiers, includingan exchange handler 312, an account handler 314, and a user handler 316.Each of the handlers 312, 314, 316 can be run on separate servers, orthey can all be run on the same server, or any combination thereof.Multiple instances of each tier can be run at the same time to achieveload balancing and fallover redundancy. Each tier communicates with theothers using messages sent over TCP/IP sockets, multicast or MicrosoftMessage Queue services.

The exchange handler 314 typically deals with the communication with theactual futures exchanges, such as CBOT 302, CME 304, and Eurex 306. Thistier effectively provides a common interface for the rest of theapplications to communicate with different exchange technologies (suchas LIFFE Connect, FIX, etc.). For each exchange that the systemcommunicates with, a driver is typically created that deals with thetranslation between that specific exchange application program interface(API) and the varying data formats of the software application. Thedriver updates caches of information within the exchange handler 316with updates to that market data, quotes or orders. The exchange handler316 typically then deals with forwarding that information onto theaccount handlers 314 and user handlers 316 based on what informationthey have subscribed to receive.

The account handler 314 is preferably at the core of the system holdingall account related information including orders for the current day.The orders submitted by a user are typically sent through the accounthandler 314 and checked for various risk management parameters, such asmaximum size, margin requirement, etc., before being sent to an exchangehandler 312 for sending to the actual exchange. When an order isconfirmed by an exchange, or is filled or cancelled, the message isforwarded from the exchange, via the exchange handler 312, to theaccount handler 314, where the order record is updated to reflect thenew state of the order. The updated order state is then sent to theend-user via the user handler 316.

Servers for use with the present invention preferably include a userhandler 316. The user handler 316 typically deals with the connectionsestablished by the end-users with the front-end, typically via the API.Access to the system by an end-user is preferably achieved through thiscomponent. The user handler 316 preferably maintains a secure connectionwith a client 330 via SSL encryption over en internet HTTPS connection332 or a direct HTTPS connection 334, which enables authentication ofthe user of client 330 and the permissions that the user of client 330has been assigned. It is contemplated that other means of maintaining asecure connection and authenticating users and permission may heimplemented as would be appreciated by those of ordinary skill in theart.

Quote data from the exchanges and the order and trade confirms from theaccount handler 314 are preferably forwarded through the user handler316 to the end-users depending on the data that each user has subscribedto. Orders submitted and requests far data from the end-user aretypically processed through the user handler 316 first, and thenforwarded to the appropriate account handler or exchange handler.

It is advantageous to have many instances of the user handler 316 tier,preferably on multiple machines, which would allow for hundreds orthousands of users to be connected to the system at the same time. Ifone instance failed, the users connected to it would automaticallyreconnect to another instance causing minimal outage time for theend-user.

The backoffice import 318 allows users via a client computer 330 toexport account details (number, name, balance, etc.) and statements to acompany providing the hosting platform. This export is in the form of aFTP or SFTP. The hosted trading platform environment 310 preferably addsor updates account details and publishes statements on the web in theform of PDF's so that a user on a client computer 330 can access alltheir account related information from the company providing the hostedtrading platform 310 via the web. The customer back office 319 providesa source for the SFTP to the back office import 318 via the internet321.

A client computer 330 interfaces the user handler 316 of the hostedtrading platform via the internet 332 or a direct concoction 334. Aclient computer 336 is preferably a desktop computer 340 having a mouse341 as an input device. In another embodiment the client computer 330may be user a flat panel touch pad computer 342 using a touch pen 343 asan input device. Of course, other types of client computers and inputdevices may be used with the present invention to display and makeinputs on the trading screen 350.

It should be understood that the above description of the presentinvention and preferred embodiment are given by way of description andillustration, and not limitation. Many changes and modifications withinthe scope of the present invention may be made without departing fromthe spirit of the present invention, and the present invention includesall such changes and modifications.

1. A method for placing a trade order for a commodity on an electronicexchange to be executed at a futures time, said method comprising thesteps of: displaying a trading screen for a commodity market, saidtrading screen including a future time schedule and an order entryregion corresponding to each future time segment of the future timeschedule; and scheduling an order corresponding to a future time segmentby locating a pointer of a user device within an order entry regioncorresponding to the future time segment and sending an input signal viathe pointer.
 2. The method of claim 1, wherein the order is a buy orderand the order entry region is a buy order entry region.
 3. The method ofclaim 1, wherein the order is a sell order and the order entry region isa sell order entry region.
 4. The method of claim 1, wherein the orderis a buy order, and further comprising the step of: scheduling a buyorder corresponding to a future time segment by locating the pointer ofa user device within a buy order entry region corresponding to thefuture time segment and sending an input signal via the pointer.
 5. Themethod of claim 1, wherein the order is a sell order, and furthercomprising the step of: scheduling a sell order corresponding to afuture time segment by locating the pointer of a user device within asell order entry region corresponding to the future time segment andsending an input signal via the pointer.
 6. The method of claim 1,wherein the future time segments of the trading screen arechronologically incremented in equal time segments.
 7. The method ofclaim 1, wherein the trading screen includes a grid of columns and rows,wherein at least some of the rows correspond to future time segments,and a column is designated as a buy column and another column isdesignated as a sell column.
 8. The method of claim 7, wherein said gridcomprises cells corresponding to buy order entry regions and cellscorresponding to sell order entry regions.
 9. The method of claim 1,wherein the input device comprises a mouse of a computer.
 10. The methodof claim 9, wherein the user sends an input signal by pressing an inputbutton on the mouse.
 11. The method of claim 9, wherein the pointer of auser device is a display arrow of the computer mouse.
 12. A computerreadable medium having program code recorded thereon for execution on acomputer for placing a trade order for a commodity on an electronicexchange in be executed at a future time, said program code causing amachine to execute the a method comprising the steps of: displaying atrading screen for a commodity market, said trading screen including afuture time schedule and an order entry region corresponding to eachfuture time segment of the future time schedule: and scheduling an entercorresponding to a future time segment by locating a pointer of a userdevice within an order entry region corresponding to the future timesegment and sending an input signal via the pointer.